Batch processing has been associated with mainframe computers since the earliest days of electronic computing. Many organizations still rely upon mainframe computers or Unix-based infrastructures for batch processing applications, such as those run at the end of each business day. These applications are known to use a great deal of processing capacity, which is typically more expensive on such proprietary computing systems compared with similar processing capacity on commodity hardware systems. As businesses' reliance upon computer applications increase, there is an ever-increasing demand for server space, requiring companies to invest in additional servers.
As more computing applications are being used by companies, the new applications are increasingly tied to existing programs and business processes. Such interdependence upon a particular structure of computing platforms often makes updating the computing platform, or modernizing the legacy applications, more expensive if not altogether infeasible. A typical structure of legacy applications and their relationship to other computing systems, is shown in FIG. 1 as system 100. In this example, system 100 includes separate computing systems for a user interface 102, data sources 104, batch processing 106, and external systems/data warehouse 108. The user 110 communicates with the system 100 through user interface 102. User interface 102 is in electronic communication with data sources 104. Data sources 104 provides input to, and receives resultant data from, batch processing 106. External systems/data warehouse 108 also receives resultant data from batch processing 106. Using current technology, if a company would like to update their batch processing capability, there is a significant investment in computer re-programming, and frequently all four of these different system components (102, 104, 106, and 108) must be updated with costly rewrites of computer code, to be able to work with the new batch processing program. Furthermore, there is also a risk of missing timelines due to unknown application logic conversion issues with user interfacing systems.
One known solution is exemplified by the system 100′ illustrated in FIG. 2. In this example, when the computer code of batch processing 106′ is changed or updated, the computer code in other parts of system 100′ must also be updated in order to communicate and effectively work with the new computer code of batch processing 106′, including user interface 102′, data sources 104′, and external systems/data warehouse 108′. Such an investment in computer programming cost must be weighed against the benefit of investing in a new batch processing system, in a total cost of ownership (“TCO”) analysis. Often the reprogramming cost results in a higher TCO, thus preventing companies from being able to enjoy such higher processing speeds. This problem only grows over time, as more applications come online that are tied to such legacy systems, making switching ever more costly.
Even with these barriers, there are some existing solutions to assist companies in reducing their reliance on costly legacy applications. In addition to rewriting the system as illustrated in FIG. 2, one current known solution offered in the marketplace, or discussed in research, calls for conversion of end-to-end applications and hosting to new software platforms. Most of the methods recommend moving applications to distributed platforms involving the licensed software and hardware such as to distributed platforms involving licensed software and hardware such as Oracle/DB2 running on Unix-based servers.
One such solution is a program called NeoBatch by Alchemy Solutions, a Microsoft gold-certified partner for migrating mainframe computing applications that use the Microsoft Windows platform. NeoBatch utilizes Windows servers for additional computing power, and a SQL server database for data storage. However, the user organization must purchase the proprietary software, and its use may require conversion of code for other applications, including user interface applications, to Windows processing platform .NET. Furthermore, the batch processing system may need to be converted to computing language NeoCOBOL to effectively communicate with Windows servers. The reliance on additional Microsoft compatible software may require a company to purchase additional licenses, which adds to the TCO. Also, the case studies showing it use, have not proven its effectiveness on migration of over 1000 million instructions per second (“MIPS”) processing requirements.
Another known solution, as exemplified by the article “Shared Cluster Scheduling: a Fair and Efficient Protocol,” by P. Michiardi, A. Barbuzzi, and D. Carra, 2011, teaches a scheduling algorithm for a fair resource allocation and jobs optimization in a shared cluster. However, there are limits to the benefits of optimization and resource allocation within a mainframe computer or Unix-based infrastructure, and it may not be available in all cases, such as when the mainframe is already running at capacity.
Another potential solution to high computer processing requirements is Grid technology. Grid technology is a software framework that uses other computers' processing capacity, which are connected to a network. This technology is exemplified by SETI@home, the search for extraterrestrial life institute, which utilizes thousands of internet-connected computers to process collected data. (See, e.g., “Optimizing Batch Window by Leveraging Grid Workflows,” G. Malaiyandisamy, B. Gurna and M. Rani, 2009.) However, such technology requires an investment in additional servers and “middleware,” software used to manage workflow among a network of computers. Like other solutions, this also adds cost, and may not have a lower TCO. Unlike SETI, companies may not be able to use the computing capacity of other computers for free.
Commodity hardware systems are often times a lower cost framework for computer processing, and do not rely upon a proprietary mainframe computer or a Unix-based infrastructure. It has long been known that such systems may be capable of performing batch processing at a reduced cost, but the method for doing so remains elusive. (See Gray, J. and Nyberg, C., “Desktop Batch Processing,” In Proceedings of COMPCON 94, 1994.) Furthermore, there are known risks in attempting such a feat, including missing software components, and interfaces with other systems. (Id.)
As an alternative to modernizing legacy systems, there is a need for migrating resource intensive batch processing of data currently processed on legacy mainframe systems to lower cost commodity hardware systems, while at the same time maintaining existing user interface, data source, and external systems. Such a system would reduce computer processing costs, while maintaining the complex user interfaces and business logic systems that are used on existing platforms.